Update

Read below for a description of the problem. The update is that this can almost be handled with the code the way it is now. These copies are really more like templates. And templates are a generalizatoin of the way student data is working. So in the same way that a student data object has an authored object. An authored object can have a template object. The current design of the object service almost makes this possible. We need to keep this in mind if we move to emf.

Original Text Below

Currently in the teemss content and in the MAC content there are objects that could be defined in
one place and then referenced in many other places. However some of these object then have student
state that is associated with them.
In the teemss content these are mainly data collectors. The same data collector is used in several
places throughout the units.

There is a facility for doing object references in the OTrunk, however this aren't enough in this case. With an object reference there is still only one object. So any state a user creates only has one place to go. So a question that is referenced twice will be linked. The current solution is to make a literal copy of the object so there are two or more places for the state to be stored.

Currently we handle this with an extra layer. The is a one data collector saved in the database and then references
to this collector stored in the units. When the OTrunk objects are created the data collector is literally copied once for each reference.
This is bad for a few reasons.

1. It means we always need that extra layer if someone was authoring content directly with OTrunk objects they wouldn't have this extra layer and would have to do these extra copies.
2. The data is repeated so it makes the content larger than it has to be.
3. If the reports are self contained in the OTrunk then these reports won't know that these multiple data collectors
   are really all exactly the same.

So it would be better if the OTrunk had the ability to handle these object copies internally. In any solution to this problem even with the extra layer we are currently using there are 2 issues:

1. nested objects
   If the copied object has object inside of it they must be copied too. There could be cycle. Initially these cycles can be forbidden. I'm pretty sure the can be detected. It might also be possible to handle them in some automatic way.

1. references to the copied object and nested objects
   When a student creates state that is for one of these copied objects or an object inside of it, this state needs
   to have a reference or be linked to this copied object. This is the state can be retrieved later either to restore the object in the same context, or for doing an external report on the state.
   The current OTrunk system doesn't have a clean way to handle this. Either all the sub-objects in the copied object would need to be assigned globally unique ids, or there would need to be some transient or chained id facility in the OTrunk.
   The chained id concept seems the best. These "chained" ids would be stored in some cases, and they would be used for lookups. There is already a specific chained id lookup used to find a students state for a particular object. In this case the chain consists of the particluar authored object and the students id.
   If this was generalized, then when the student map contained an id to a object it might be a chained id which is an id to the copied object and the id of the original sub-object. A report would then ask the student map for the student state associated with this chain.

We will need to do this anyhow in this first version but it will be more explicit. The layer that copies the datacollector will need to also copy the sub objects and assign modified local ids to them. Then the import will need to map these local ids to global ids. And when someone wants to do a report on a datacollector they will need to construct the modified local id. First they get the local_id of the data collector then they add the id of the response where the datacollector is used. This id is then mapped to the global id of the particular data collector.
If the report needs a sub object like the data store inside the data collector. Then the report would get the global id of the copy and then either traverse it down to the data store, or it would figure out the modified local id of the data store and then the global id, and then ask for the student answers.